ETSITS132 541 vn.o.o 



(2012-10) 




Digital cellular telecommunications system (Phase 2+); 
Universal Mobile Telecommunications System (UMTS); 

LTE; 

Telecommunication management; 

Self-Organizing Networks (SON); 

Self-healing concepts and requirements 

(3GPP TS 32.541 version 11.0.0 Release 11) 



^ 



Advanced 



ibit^iii 



A filOBAL INITIATIVE 



3GPP TS 32.541 version 1 1 .0.0 Release 1 1 1 ETSI TS 1 32 541 V1 1 .0.0 (201 2-1 0) 



Reference 



RTS/TSGS-0532541vb00 
Keywords 



GSM,LTE,UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2012. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS'^" and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 
2QppTM ^^^ LTETM are Trade Marks of ETSI registered for the benefit of its Members and 

of the 3GPP Organizational Partners. 
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 32.541 version 1 1 .0.0 Release 1 1 2 ETSI TS 1 32 541 V1 1 .0.0 (201 2-1 0) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 32.541 version 1 1 .0.0 Release 1 1 3 ETSI TS 1 32 541 V1 1 .0.0 (201 2-1 0) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 5 

Introduction 5 

1 Scope 6 

2 References 6 

3 Definitions and abbreviations 6 

3.1 Definitions 6 

3.2 Abbreviations 7 

4 Concepts and background 7 

4.1 Overview 7 

4.1.1 General description 7 

4.1.2 Recovery actions 8 

4.1.3 General Self-healing procedure 8 

4.2 Self-healing Concept 1 

4.2.1 Logical Function Blocks 1 

4.2.1.1 Self-healing Input Monitoring Function (SH_MON_F) 1 

4.2.1.2 Self-healing Diagnosis Function (SH_DG_F) 1 

4.2.1.3 Triggering Recovery Action/s Function (SH_TG_F) 1 

4.2.1.4 Self-healing Evaluating Function (SH_EV_F) 1 

4.1.2.5 Self-healing Fallback Function (SH_FB_F) 1 

4.2.1.6 NRM IRP Update Function (NRM_UF) 1 

4.2.1.7 Self-healing Monitoring and Management Function (SH_MMF) 1 

4.2.1.7.1 Self-healing Monitoring and Management Function (SH_MMF_NM) 1 

4.2.1.7.2 Self-healing Monitoring and Management Function (SH_MMF_EM) 1 

4.2.1.8 Self-healing of Cell Outage Function (SH_CO_F) 1 

4.2.1.9 Self Recovery of NE software Function (SR_NSW_F) 1 

4.2.1.10 Self-healing of Board Fault Function (SH_BF_F) 1 

5 Business level requirements 12 

5.1 Requirements 12 

5.2 Actor roles 12 

5.3 Telecommunications Resources 12 

5.4 High-Level use case 13 

5.4.1 Alarm Triggered Self-healing 13 

5.4.2 Cell outage scenarios 13 

6 Specification level requirements 14 

6.1 Requirements 14 

6.1.1 Monitoring and Management part 14 

6.1.2 Self-healing of Cell Outage Function 14 

6.2 Actor roles 15 

6.3 Telecommunications Resources 15 

6.4 Use case 15 

6.4.1 Self Recovery of NE Software 15 

6.4.2 Self-healing of board faults 16 

6.4.3 Self Healing of Cell Outage 17 

6.4.3.1 Use case Cell Outage Detection 17 

6.4.3.2 Use case Cell Outage Recovery 17 

6.4.3.3 Use case Cell Outage Compensation 18 

6.4.3.4 Use case Return from Cell Outage Compensation 18 

7 Functions and Architecture 19 

7.1 Self-healing Logical Architecture 19 



£75/ 



3GPP TS 32.541 version 1 1 .0.0 Release 1 1 4 ETSI TS 1 32 541 V1 1 .0.0 (201 2-1 0) 

7.2 Self-healing Reference Model 20 

Annex A (informative): Change history 21 

History 22 



£75/ 



3GPP TS 32.541 version 1 1 .0.0 Release 1 1 5 ETSI TS 1 32 541 V1 1 .0.0 (201 2-1 0) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



rd , 



The present document is part of a TS-family covering the 3 Generation Partnership Project Technical Specification 
Group Services and System Aspects, Telecommunication management; as identified below: 

32.541: 'Self-Organizing Networks (SON); Self-Healing Concepts and Requirements' 

Stage 2 for Self-Healing is not in a TS of its own. Stage 2 for selected Self-Healing functions is or will be part of 32.522 
[6] and 32.762 [7]. 
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Scope 



The present document describes concept and requirements of OAM for Self-Healing of Self-Organizing Networks 
(SON). 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1]. 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.1 1 1-1: "Telecommunication management; Fault Management; Part 1: 3G fault 

management requirements". 

[4] 3GPP TS 32.301: "Telecommunication management; Configuration Management (CM); 

Notification Integration Reference Point (IRP): Requirements". 

[5] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[6] 3GPP TS 32.522: "Telecommunication management; Self-Organizing Networks (SON) Policy Network Resource 
Model (NRM) Integration Reference Point (IRP); Information Service (IS)" 

[7] 3GPP TS 32.762: "Telecommunication management; Evolved Universal Terrestrial Radio Access Network (E- 
UTRAN) Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS)" 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [5] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [5] . 

alarm: See 3GPP TS 32.111-1 [3]. 

Cell Outage: Cell outage is the total loss of radio services in the coverage area of a cell. 

fault: See3GPPTS 32.111-1 [3]. 

Stop condition: The Self-healing procedure may include one or more iterations until the related fault is resolved or the 
thresholds of some parameters (e.g. iteration counter or iteration duration time, etc.) are reached. These thresholds may 
be used to determine whether to stop the procedure if the related fault is still not resolved after several iterations or a 
long time. We call these thresholds as well as fault resolution the stop conditions. 

Self-healing Process: When a TCoSH is reached, particular action(s) will be triggered to solve or mitigate the 
particular fault. 
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Self-healing Function: a Self-healing Function is to monitor a particular TCoSH and then, if necessary, to trigger a 
Self-healing Process to solve or mitigate the particular fault. 

Trigger Condition of Self-Healing (TCoSH): it is the condition which is used to judge whether a Self-healing Process 
needs to be started. This condition could be an alarm or the detection of a fault. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [5] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 2 1.905 [5]. 

AD AC Automatically Detected and Automatically Cleared 

ADMC Automatically Detected and Manually Cleared 

EM Element Manager 

EPC Evolved Packet Core 

E-UTRAN Evolved Universal Terrestrial Radio Access Network 

NE Network Element 

NM Network Manager 

0AM Operation Administration Maintenance 

SON Self Organizing Networks 

TCoSH Trigger Condition of Self-Healing 

UE User Equipment 

4 Concepts and background 

4.1 Overview 

4.1.1 General description 

Self-healing is a functionality of SON. The purpose of Self-healing is to solve or mitigate the faults which could be 
solved automatically by triggering appropriate recovery actions. 

From the point of view of fault management, for each detected fault, appropriate alarms shall be generated by the faulty 
network entity, regardless of whether it is an AD AC or an ADMC fault. 

The trigger of Self-healing can be an alarm. In this case, the Self-healing functionality monitors the alarms, and when it 
finds alarm/s which could be solved automatically, it gathers more necessary information (e.g. measurements, testing 
result, etc) and does deep analysis, and then according to the analysis result, if necessary, it triggers appropriate 
recovery actions to solve the fault automatically. 

For some Self-healing functions which are located in NEs and require more rapid response, the trigger of Self-healing 
can be the detection of a fault. Hence, when a fault is detected, an appropriate Self-healing Process will be triggered to 
try to heal the fault automatically. 

The Self-healing functionality also monitors the execution of the recovery action/s and decides the next step 
accordingly. After a Self-healing procedure ended, the Self-healing functionality shall generate and forward appropriate 
notifications to inform the IRPManager about the Self-healing result and all the information of the performed recovery 
actions may be logged. 
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4.1.2 Recovery actions 

In the case of software faults, the recovery actions may beD 

a) system initializations (at different levels), 

b) reload of a backup of software, 

c) activation of a fallback software load, 

d) download of a software unit, 

e) reconfiguration, etc. 

In the case of hardware faults, the recovery actions depend on the existence and type of redundant (i.e. back-up) 
resources. 

If the faulty resource has no redundancy, the recovery actions may be: 

a) Isolate and remove the faulty resource from service so that it does not disturb other working resources; 

b) Remove the physical and functional resources (if any) from the service, which are dependent on the faulty 
one. This prevents the propagation of the fault effects to other fault-free resources; 

c) State management related activities for the faulty resource and other affected/dependent resources; 

d) Reset the faulty resource; 

e) Other reconfiguration actions, etc. 

If the faulty resource has redundancy, the recovery action shall be changeover, which includes the action a), c) and d) 
above and a specific recovery sequence. The detail of the specific recovery sequence is out of the scope of the present 
document. 

In the case of other kinds of faults, the recovery actions are FFS. 

4.1 .3 General Self-healing procedure 

The Self-healing Function has two parts: the monitoring part and the healing process part. The logic view of the general 
Self-healing procedure is shown in figure 4.1.3-1: 
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Monitoring Part: 



-Loop: Always running- 



[SHOl] 



Monitor the TCoSHs 




Trigger an appropriate Self-healing 
Process 



Do nothing 



Healing Process Part: 
[SH03] 



No 



Get necessary information 

(measurements, CM data, testing 

result, etc) 



[SH04] 



1 



Analyse and Diagnose 
(i.e. identify recovery actions) 




[SH05] 

Backup the related configuration 
data if needed 

[SH06] 



Trigger the execution of recovery 
actions 



[SH07] 



Yes 



[SHIO] 



End 



Log the information of the 

performed recovery actions if 

needed 




[SH09] 

Emit a notification to report the 
result. 



-Yes 

[SH08] 



If necessary, fallback is 
executed 



Yes- 



Figure 4.1.3-1 : logic view of the general Self-healing procedure 
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The general Self-healing procedure includes following steps: 

[Monitoring part:] 

[SH01]The Self-healing Function monitors the TCoSHs continuously. 

[SH02]When a TCoSH is reached, then an appropriate Self-healing Process shall be triggered. 

[Heahng process part:] 

[SH03]The Self-healing Function gathers more necessary information (e.g. measurements, CM data, testing result, 
etc). 

[SH04]Based on the TCoSH and gathered information, the Self-healing Function does deep analysis and diagnosis, 
and gives the result. If the result includes recovery action/s, then go to next step, if not, go to End. 

[SH05] The configuration data prior to the executing of the recovery action/s is backed up if needed. 

[SH06]If necessary, the Self-healing Function triggers the executing of the recovery action/s. 

[SH07] The Self-healing Function evaluates the result of the self-healing recovery action/s: 

If the fault hasn"t been solved and the stop condition/s is not reached, then the self-healing runs again, i.e. go 
to SH03. 

If the fault has been solved, then go to [SH09]. 

If the stop condition/s is reached, then: 

[SH08] If necessary, fallback is executed. Go to [SH09]. 

[SH09] The Self-healing Function emits a notification to report the result of the Self-healing Process. 
[SHIO] If necessary, the Self-healing Function logs the information of the performed recovery actions and the 
occurrence of important events during the self-healing process. 



RemarkDThe detailed healing process part of the individual self-healing use cases may differ from this general 
description, for example: 

1) The order of the bullet points in the list does not imply any statement on the order of execution. 

2) In [SH05], whether the backup of the configuration data is needed and which configuration data should be 
backed up shall be decided on a use case by use case basis. 

3) In [SH08], whether a fallback is needed shall be decided on a use case by use case basis. 

4) In [SHIO], whether log is needed and the detail of the logged information shall be decided on a use case by use 
case basis. 
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4.2 Self-healing Concept 

4.2.1 Logical Function Blocks 

4.2.1 .1 Self-healing Input Monitoring Function (SH_l\/ION_F) 

This functional block supports the following steps: [SHOl], [SH02] (See clause 4.1.3). 

4.2.1 .2 Self-healing Diagnosis Function (SH_DG_F) 

This functional block supports the following step: [SH04] (See clause 4.1.3). 

4.2.1 .3 Triggering Recovery Action/s Function (SH_TG_F) 

This functional block supports the following step: [SH06] (See clause 4.1.3). 

4.2.1 .4 Self-healing Evaluating Function (SH_EV_F) 

This functional block supports the following step: [SH07] (See clause 4.1.3). 

4.1 .2.5 Self-healing Fallback Function (SH_FB_F) 

This functional block supports the following step: [SH08] (See clause 4.1.3). 

4.2.1 .6 NRIVI IRP Update Function (NRI\/I_UF) 

This function updates the E-UTRAN and EPC NRM IRP with the self-healing modification, if needed. 

4.2.1 .7 Self-healing IVIonitoring and IVIanagement Function (SH_I\/II\/IF) 

Editor's note: This functional block supports the following functions: FFS. 

This function monitors the self-healing process and provides the operator with the necessary information of the self- 
healing process. This function shall be able to get information about all other functional blocks. In addition to this, it 
allows the operator to control the execution of the self-healing process. 

4.2.1 .7.1 Self-healing Monitoring and Management Function (SHMMFNM) 

SH_MMF_NM (IRP Manager): representing the NM portion of SH_MMF (necessary monitoring and limited 
interaction capabilities to support a self-healing process), as well as related IRPManager functionality. 

4.2.1 .7.2 Self-healing Monitoring and Management Function (SHMMFEM) 

SH_MMF_EM (IRP Agent): representing the portion of SH_MMF operating below Itf-N, as well as related IRP Agent 
functionality. 

4.2.1 .8 Self-healing of Cell Outage Function (SH_CO_F) 

This function handles the self-heahng function for cell outage. 

4.2.1 .9 Self Recovery of NE software Function (SR_NSW_F) 

This function handles the self-healing function of recovery of NE software. 

4.2.1 .10 Self-healing of Board Fault Function (SH_BF_F) 

This function handles the self-healing function for board fault. 
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Business level requirements 



5.1 Requirements 



REQ_SH_CON_001 It should be possible for the self-healing actions to be confirmed by the IRPManager before they 
are executed. 

REQ_SH_CON_002 The Self-healing functionality shall be performed with minimal human intervention. 

REQ-SH- CON-003 The IRP Agent shall support a capability allowing the IRPManager to know the success or failure 
result of Self-healing. 

REQ-SH-CON-004 The IRPAgent should support a capability allowing the IRPManager to monitor the self-healing 
actions. 

REQ-SH-CON-005 The self-healing complex corrective actions shall be executed in a consistent and coordinated way. 

REQ-SH-CON-006 The IRPAgent or eNB should perform the necessary reconfigurations during a cell outage. If that 
is not or only partly possible or not supported, then the IRPAgent should indicate the need for assistance to the 
IRPManager. 

REQ_SH_CON_007 The IRPAgent shall support a capability allowing the IRPManager to know which alarms are 
associated with a self-healing operation, which is in progress. 

5.2 Actor roles 



5.3 Telecommunications Resources 
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5.4 High-Level use case 
5.4.1 Alarm Triggered Self-healing 



Use Case 
Stage 


Evolution / Specification 


«Uses» 

Related 

use 


Goal (*) 


In the 0AM system, the alarms are monitored in real-time. When an alarm which can be self-healed is 
raised, it is treated as the trigger of the Self-healing and the gathering of correlated information. By 
gathering the correlated information and further analysis, the self-healing actions of the fault shall be 
triggered. 




Actors and 
Roles (*) 


Self-healing function, IRPManager 




Telecom 
resources 


The E-UTRAN/EPC network including its OSS. 




Assumptions 


The network is properly installed and running. 




Pre conditions 


Network is in normal operation. 




Begins when 


Automatically triggered when an alarm received, the alarm may be emitted by NE or 0AM system. 




Step 1 (*) (M) 


The Self-healing functionality monitors the alarms, and when it finds alarm/s which can be solved 
automatically, goes to step 2. 




Step 2 (*) (M) 


It gathers more necessary information (e.g. measurements, CM data, testing result, etc). 




Step 3 (*) (M) 


Based on the alarm and gathered information, it does deep analysis and diagnosis, and may give the 
result, i.e. recovery actions. 




Step 4 (*) (M) 


If necessary, it triggers appropriate recovery actions to solve the fault automatically. 




Step 5 (*) (M) 


It evaluates the result of self-healing: 

If the fault hasn"t been solved and the stop condition/s is not reached, then the self-healing runs again. 




Ends when (*) 


Ends when it finds that the fault has been solved or it finds that the recovery is failed or the result of 
step 3 gives no recovery action or when an exception occurs. 




Exceptions 


FFS. 




Post 
Conditions 


If the fault has been solved, then the alarm is disappeared. A notification is raised to report the Self- 
healing result, and the information of the performed recovery actions is logged. 




Traceability (*) 







5.4.2 Cell outage scenarios 

1. Loss of total radio services in the coverage area of a cell 

In this scenario, when there is a loss of total radio services in the outage cell, all the UEs cannot estabUsh or maintain all 
the Radio Bearers (RBs) via that particular cell. For example, all the Cell Center Users (CCU) and Cell Edge Users 
(CEU) cannot establish the RRC connection in the outage Cell A. 



Cell A 




Figure 5.4.2-1 : Loss of total radio services in the coverage area of a cell 
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6 Specification level requirements 

6.1 Requirements 

6.1 .1 Monitoring and Management part 

REQ_SH_FUN_001 The IRP Agent should provide information to the IRPManager about the self-heahng actions. The 
specific activities to be reported to the IRPManager by each Self-Healing function will be determined on a use case by 
use case basis. 

REQ_SH_FUN_002 The IRP Agent shall provide information to the IRPManager about the self-healing results. 

REQ_SH_FUN_003 The IRP Agent shall support a capability allowing the IRPManager to enable and disable the self- 
healing functionalities on a use case by use case basis. 

REQ-SH-FUN-004 The IRP Agent shall support a capability allowing the IRPManager to get the information (e.g. a 
list) of the supported Self-healing Functions on a use case by use case basis. 

REQ-SH-FUN-005 The IRP Agent shall support a capability allowing the IRPManager to get the status (enabled or 
disabled) of the Self-healing Functions on a use case by use case basis. 

REQ-SH-FUN-006 The IRP Agent shall support a capability allowing the IRPManager to be notified (according to TS 
32.301 [4]) of the start and end of Self-healing action on a use case by use case basis. 

REQ-SH-FUN-007 The IRP Agent shall provide information to the IRP Manager that allows the IRP Manager to 
identify which alarms are associated with a self healing operation which is in progress on a use case by use case basis. 

6.1 .2 Self-lnealing of Cell Outage Function 

REQ_SHCOC_FUN_l 

The IRP Agent shall inform the IRPManager about begin and end of a cell outage compensation. 

REQ_SHCOC_FUN_2 

The IRP Agent should provide the IRPManager the possibility to know the result of a cell outage recovery. 

REQ_SHCOC_FUN_3 

The IRP Agent shall provide the IRPManager the possibility to know the result of a cell outage compensation. 

REQ_SHCOC_FUN_4 

The IRP Agent should provide the IRPManager the possibility to define which cells are allowed or prohibited to be 
reconfigured for cell outage compensation. 
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6.2 



Actor roles 



6.3 



Telecommunications Resources 



6.4 



Use case 



6.4.1 Self Recovery of NE Software 



Use Case Stage 


Evolution / Specification 


«Uses» 

Related 

use 


Goal (*) 


The NE software is recovered to the initial status or the status of latest backup, to ensure the NE 
software runs normally. 




Actors and Roles 

(*) 


IRPManager and Self-healing function 




Telecom 
resources 


The E-UTRAN/EPC network including its OSS. 




Assumptions 


The network is properly installed and running. 




Pre conditions 


The operator has the initial backup or the latest backup of the NE software and configuration data. 

The NE Software Self Recovery function is started. 

The monitoring part of the NE Software Self Recovery function monitors the TCoSH continuously. 




Begins when 


A TCoSH of this function is detected. 




Step 1 (*) (M) 


Self-healing Process of the NE Software Self Recovery is triggered to heal the fault : 

Verify the version of software, if it is found that the software is destroyed, restore the backup of the 

destroyed software. 

Check the configuration data, if it is found that the configuration data is incorrect, reconfigure or 

restore the configuration data. 

If necessary, restart the process. 

If it is still abnormal after the healing procedure, a notification shall be raised to notify the 

IRPManager. 




Ends when (*) 


Ends when all steps identified above are completed or when an exception occurs. 




Exceptions 


FFS. 




Post Conditions 


The NE software is running normally or the operator processes the problem manually. 




Traceability (*) 







This use case is typically covered by existing functionality in most products. No additional specification requirements 
are identified. 
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6.4.2 Self-healing of board faults 



Use Case 
Stage 


Evolution / Specification 


«Uses» 

Related 

use 


Goal (*) 


System detects board faults and mitigates or solves them automatically to avoid user impact (E.g. 
system switch to standby board automatically when active board malfunctions). 




Actors and 
Roles (*) 


IRPManager and Self-healing Function 




Telecom 
resources 


The E-UTRAN/EPC network including its OSS. 




Assumptions 


The network is properly installed and running. 




Pre conditions 


Network is in normal operation. 

The board faults Self-healing function is started. 

The monitoring part of the board faults Self-healing function monitors the TCoSH continuously. 




Begins when 


A TCoSH of this function is detected. 




Step 2 (*) (M) 


Self-healing Process of this function is triggered to heal the fault : 

A) The Self-healing functionality collects the redundant information of the faulty board, and 
processes accordingly: 

• If there is a stand-by board and the stand-by board is in operational state, then the failed board 
will be blocked and a changeover will be started automatically. Reset the blocked board, if it turns 
to normal, then it treated as the redundant board. 

• If there is not a redundant board or the redundant board is in abnormal state, then the failed 
board will be blocked. 

B) A notification shall be raised to notify the IRPManager about the healing result. 




Ends when (*) 


Ends when all steps identified above are completed or when an exception occurs. 




Exceptions 


FFS. 




Post 
Conditions 


The device is running normally or the operator processes the problem manually. 




Traceability (*) 







This use case is typically covered by existing functionality in most products. No additional specification requirements 
are identified. 
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6.4.3 Self Healing of Cell Outage 



6.4.3.1 



Use case Cell Outage Detection 



Use Case 
Stage 


Evolution / Specification 


«Uses» 

Related 

use 


Goal (*) 


System detects a cell outage (e.g. sleeping, out-of-service, etc.) automatically. 




Actors and 
Roles (*) 


IRPManageras user 




Telecom 
resources 


The E-UTRAN/EPC network including its OSS. 




Assumptions 


N/A 




Pre conditions 


The network is properly installed and running. 




Begins when 


N/A 




Step 1 (*) (IVI) 


The input parameters (KPIs, alarms, etc.) are monitored continuously by cell outage detection 
function. 




Step 2 (*) (IVI) 


When the monitored parameters meet the cell outage detection condition, e.g.when there is a cell 
outage related alarm or the value of one KPI crossed the threshold, the cell outage is detected. 




Step 3 0(0) 


IRPManager got information about the cell outage. 




Ends when (*) 


Ends when all steps identified above are completed or when an exception occurs. 




Exceptions 


One of the steps identified above fails and retry is unsuccessful. 




Post Conditions 


In case of success of step 1 and step 2: Cell outage is detected. 
In case of exception in step 1 or step 2: Cell outage is not detected. 




Traceability (*) 


FFS 





6.4.3.2 



Use case Cell Outage Recovery 



Use Case 
Stage 


Evolution / Specification 


«Uses» 

Related 

use 


Goal 


System recovers a cell outage (e.g. sleeping, out-of-service, etc.) automatically 




Actors and 
Roles 


Cell outage recovery function, IRPManager 




Telecom 
resources 


The E-UTRAN/EPC network including its Management Systems. 




Assumptions 


The network is properly installed and running. 




Pre conditions 


A cell-outage was detected. 




Begins when 


Information about cell-outage is available to Cell Outage recovery function. 




Step 1 (M) 


Try recovery action/s (examples: switch to redundant hardware if the fault is caused by malfunction of 
redundant entity, re-establish or re-configure the cell, software restart etc.) 




Step 2 (0) 


Reporting of the Cell Outage Recovery results to the IRP Manager 




Ends when 


Ends when all steps identified above are completed or when an exception occurs. 




Exceptions 


Recovery action/s is/are not successful. 




Post Conditions 


In case of success: Cell outage ended. 
In case of exception: Cell outage persists 




Traceability 







£75/ 



3GPP TS 32.541 version 11.0.0 Release 11 



18 



ETSI TS 132 541 V1 1.0.0 (2012-10) 



6.4.3.3 



Use case Cell Outage Compensation 



Use Case 
Stage 


Evolution / Specification 


«Uses» 

Related 

use 


Goal 


System compensates a cell outage (e.g. sleeping, out-of-service, etc.) automatically to maintain as 
much as possible normal services to the network users 




Actors and 
Roles 


IRPManager 




Telecom 
resources 


The E-UTRAN/EPC network including its Management Systems. 




Assumptions 


The network is properly installed and running. 

Optional assumption: IRPManager is continuously aware about configuration information and other 
relevant data in order to support an efficient and effective re-configuration when a compensated cell 
outage ends. 




Pre conditions 


A cell-outage was detected and is still ongoing. 
Cell-outage recovery - if attempted - was not yet successful. 




Begins when 


Cell outage compensation function (COCF) is informed about a detected cell-outage. 




Step 1 (CO) 


Current configuration information and other relevant data are gathered in order to support an efficient 

and effective re-configuration when a compensated cell outage ends. 

Remark: Depending on the type of outage some configuration information may not be available. 

Condition: Continuous awareness of configuration information (see optional assumption above) is not 

there. 




Step 2 (M) 


Reconfiguration of related neighbouring eNBs to compensate the cell outage. 




Step 3 (0) 


Make changed configuration which was done for the Cell Outage Compensation (see step 2) 
available to the IRP Manager 




Ends when 


Ends when all steps identified above are completed or when an exception occurs. 




Exceptions 


One of the steps identified above fails and retry is unsuccessful. 




Post 
Conditions 


Impact of cell outage on end user experience is minimized. 




Traceability 







6.4.3.4 



Use case Return from Cell Outage Compensation 



Use Case 
Stage 


Evolution / Specification 


«Uses» 

Related 

use 


Goal 


System returns to normal operation after a cell outage compensation 




Actors and 
Roles 


IRPManager 




Telecom 
resources 


The E-UTRAN/EPC network including its Management Systems. 




Assumptions 


The network is properly installed and running. 

Optional assumption: IRPManager is continuously aware of configuration information and other relevant 

data in order to support an efficient and effective re-configuration when a compensated cell outage ends 




Pre conditions 


Cell outage compensation is applied. 




Begins when 


End of cell-outage is announced to the COCF. 




Step 1 (M) 


System checks if a cell outage compensation was done for the ended cell outage. 




Step 2 (CO) 


Current configuration information and other relevant data are gathered in order to support an efficient 

and effective re-configuration. 

Condition: Continuous awareness of configuration information (see optional assumption above) is not 

there. 




Step 3 (M) 


Reconfiguration of related neighbouring eNBs and formerly failed cell to remove compensation of the 
cell outage. This should lead to the same configuration as before the cell outage in case the 
configuration itself was not the reason for the cell outage and in case the cell neighbourhood, topology 
did not change since the beginning of the cell outage. 




Step 4 (0) 


Make changed configuration after the Cell Outage available to the IRP Manager 




Exceptions 


One of the steps identified above fails and retry is unsuccessful. 




Post 
Conditions 


The involved cells are re-configured. 




Traceability 
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7 



Functions and Architecture 



7.1 Self-healing Logical Architecture 

The lines between the functional blocks do not indicate specific 3GPP interfaces. 
For the abbreviations used, please see the headlines of clause 4. 



1 



Actor 



SH MMF 



I 



I 



I 



SH MON F 



SH TG F 



SH DG F 



SH EV F 



SH FB F 



NRM UF 



SH CO F SR NSW F 



SH BF F 



Figure 7.1-1: Self-healing Logical Architecture 
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7.2 Self-healing Reference Model 

The SH_MMF has a part located in the EM and a part located at the NM. 
For the abbreviations used, please refer to clause 4. 



SH_MMF_NM 
(IRPManager) 



SH_MMF_EM 
(IRPAgent) 



I 



I 



Itf-N 



I 



SH MON F 



SH TG F 



SH DG F 



SH EV F 



SH FB F 



NRM UF 



SH CO F 



SR NSW F 



SH BF F 



Figure 7.2-1 : Self-healing Reference Model 
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